I think we can cache readTsconfigCompilerOptions using (and the same for readTsconfigCompilerOptions below)

this.tsconfigProcessorCache = new WeakMap<TS_CONFIG_JSON_VALUE, { aliases: Aliases, references: References }>;

So we will read everything only on the first run, and will keep results until GC allow it

Feel free to think how we can avoid more tasks on the second and third calls

What if we just store the data on this.tsconfigPathsData?
It doesn’t need to be garbage-collected anyway, so the cache implementation doesn’t have to be too complex.

Can you describe these checks? Maybe we can just check if exist?

The goal here is to resolve the extendedConfigValue path from node_modules, e.g. extends: "react/tsconfig". Reference: https://github.com/jonaskello/tsconfig-paths/blob/master/src/tsconfig-loader.ts#L187

Added a test case here https://github.com/webpack/enhanced-resolve/pull/463/files#diff-91224cf57750b2195ca9c17182d982488414303921bf1332a7e1081ed05953b1R2

We can cache this, look at ExportsFieldPlugin.js plugin, we have this.fieldProcessorCache to cache processed export fields, so let's use the same logic, just using this.tsconfigProcessorCache name and cache result of this function

The tsconfigPathsToResolveOptions function only runs once per resolve. However, the key of this.fieldProcessorCache is JsonObject(ExportsFieldPlugin.fieldProcessorCache: WeakMap<JsonObject, FieldProcessor>), and since each resolve produces a different JsonObject reference, this cache becomes ineffective in scenarios where it should run only once per resolve. This makes me wonder whether the cache in ExportsFieldPlugin(this.fieldProcessorCache) aligns with the original intent—perhaps the key should be a string rather than an object reference.